1. I want you to check Concurrency Control
   I'm afraid of:

• Race conditions in version calculation
• Conflicting bot commits
• Duplicate release PRs. Please validate this assumption

According docs, the bottom line: "Use concurrency to ensure that only a single job or workflow using the same concurrency group will run at a time."

Concurrency:
  group: smart-release-please-${{ github.ref }}
  cancel-in-progress: false  # false to queue, not cancel

2. Missing Python Setup
   Official Documentation: GitHub-hosted runners include Python, but the best practice is explicit setup.
3. What happens with other conventional? Like "chore"? Or if you release only "chore" from all commits, it seems it won't create or update the rc
4. It seems it ++ on each commit, if it update patch and you have 5 commits before merging to "next" branch,h the rc will be from "rc1" to rc6.6.

Can we add some basic logs \ output on the version that has been calculated before creating release-please new release candidate? for understanding and debugging? Some minimum log data

6. For debug ability, is there any option to add some "dry-run" non-default scenario so we can dispatch and check on future problems?
7. Add the mermaid 3 base flow so it will be understandable what the flow does, becaouse its complex flow that contains algorithmic calculation
8. consider reduce the test toa minimuml (test py file) and add it as part of the repo as a unit test to be sure we cover our logic (best practice as a developer :))

1. concurrency: this is for github workflows - i tested it in jobnik-manager-test and will add it to the jobnik-manager release-please workflow next.
2. added Python setup for best practice
3. chore and other semver are upgrading the rc but aren't affect the calculated version
4. fixed by adding "--first-parent" to git command
5. logs are already present - discussed
6. dry run is now in the test workflow
7. added one mermaid
8. test file is used in test workflow